home *** CD-ROM | disk | FTP | other *** search
/ Software Vault: The Diamond Collection / The Diamond Collection (Software Vault)(Digital Impact).ISO / cdr35 / invb601d.zip / MANUAL.TXT < prev    next >
Text File  |  1995-01-24  |  94KB  |  1,935 lines

  1.  
  2.                      Copyright (c) 1990 - 1994
  3.          All Rights Reserved to NetZ Computing Ltd., Israel
  4.  
  5.  
  6.                           User's Guide
  7.                                and
  8.                    Installation Instructions
  9.  
  10.                 Warranty And Licensing Agreement
  11.  
  12.  InVircible and ResQdisk (Tm) 1990-1994 are trademarks and copyright
  13.  with all rights reserved to NetZ Computing Ltd. (NCL), Israel. You, as
  14.  the purchaser of license rights to the software, are herein referred to
  15.  as the Licensee. The Licensee may not assign the license rights to the
  16.  software without the prior agreement of NCL.
  17.  
  18.  The installation of this software package constitutes acceptance and
  19.  full agreement to the terms and conditions of this warranty and
  20.  licensing agreement, in so doing the Licensee agrees to be bound by
  21.  said provisions. This is a legal agreement between the Licensee as the
  22.  end user -- and NetZ Computing Ltd. who is the owner of all rights to
  23.  the software. Usage of the InVircible software indicates acceptance of
  24.  the terms and conditions.
  25.  
  26.  License: InVircible is licensed, it is not sold. The Licensee is
  27.  obtaining limited rights to use the InVircible software. The Licensee
  28.  is licensed to use InVircible on a single IBM-style personal computer.
  29.  The distribution floppy of InVircible has provisions for registering
  30.  two installations to the hard disk. Only one registered installation to
  31.  one hard disk is licensed with this disk package. The second
  32.  installation is reserved for the Licensee as a backup. Site licenses
  33.  are available for individuals or organizations with multiple
  34.  installation requirements. Alteration or reverse-engineering of the
  35.  programs is not authorized, such attempts terminate this license
  36.  agreement and may result in unpredictable and irreversible damage.
  37.  
  38.  Limited Warranty/Limitation of Remedies: Defective diskettes will be
  39.  replaced, at no charge, if they are returned freight pre-paid, within
  40.  30 days of the original purchase date. The sole remedy available to the
  41.  Licensee will be limited to the replacement of defective diskettes as
  42.  outlined, or a refund at the purchase price of this software program
  43.  package.
  44.  
  45.  InVircible is provided "as is". The Licensee assumes all responsibility
  46.  for the determination of the suitability of this software for
  47.  Licensee's configuration and the results and performance of this
  48.  software program package. NetZ Computing, the distributor, and their
  49.  suppliers do not warrant, guarantee, or make any representations
  50.  regarding the use of, or the results obtained with, the program in
  51.  terms of correctness, accuracy, reliability, legality, or otherwise. In
  52.  no event shall NetZ Computing Ltd., the distributor, nor anyone else
  53.  involved in the creation, production, or delivery, of this product be
  54.  held liable for any damages, loss of profit, consequential, or other
  55.  damages, that may arise out of the Licensee's use or inability to use
  56.  the InVircible programs. Some states do not allow excluding or limiting
  57.  implied warranties or limiting liability for incidental or
  58.  consequential damages, so the above limitation may not apply to the
  59.  Licensee. This limited warranty and license agreement is governed by
  60.  the laws of the State of Israel.
  61.  
  62.  
  63.                            Table Of Contents
  64.  
  65.  Preface
  66.  
  67.  Quick Start Instructions
  68.  
  69.  1. Introduction
  70.  1.1 What are computer viruses?
  71.  1.2 InVircible's Main Features.
  72.  
  73.  2. Getting Started.
  74.  2.1 Working from the InVircible Floppy.
  75.  2.2 Preparation of the Rescue Diskette.
  76.  
  77.  3. Using the Main Menu (IVMENU).
  78.  3.1 IVMENU Special Keys.
  79.  3.2 The IVMENU Caution Panel.
  80.  3.3 The Last IVB, IVSCAN or IVX Report.
  81.  
  82.  4. InVircible Installation .
  83.  4.1 Installation to Hard-disk.
  84.  4.2 Installation to LAN Server.
  85.  4.3 Installation Under OS/2.
  86.  4.4 Installation in the Sentry Mode.
  87.  
  88.  5. Recommended Anti-Virus Strategy.
  89.  5.1 In the Single User Environment.
  90.  5.2 In a Network Environment.
  91.  5.3 In the Institutional Environment
  92.  5.4 In Unattended Installations (e.g. Bulletin
  93.      Board Systems).
  94.  
  95.  6. IVB - The file Protection & Restoration Program
  96.  6.1 The Extra-Security Feature.
  97.  6.2 Off-line Backup of the Database-Files-Tree.
  98.  
  99.  7. IVX - The Correlation Scanner.
  100.  
  101.  8. ResQdisk - The Boot-Area and CMOS Maintenance program.
  102.  8.1 Reconstruction of the Boot Block.
  103.  8.2 Regaining Access to an "Invalid Drive".
  104.  8.3 ResQdisk's Setup Utility.
  105.  
  106.  9.  IVSCAN - The Virus Detection and Removal Scanner
  107.  9.1  Removing Generic Boot Viruses from Floppies
  108.  
  109.  10. A Primer to Generic and Special Methods.
  110.  10.1 Generic Method Selection
  111.  10.2 Generic Boot-Block Recovery
  112.  10.3 Fat Manipulators Removal
  113.  10.4 Inverse Piggy-Backing (IP).
  114.  10.5 The Virus Interrogation technique.
  115.  10.6 Forced Self Restoration.
  116.  10.7 Screening New Software.
  117.  
  118.  11. Importing InVircible into Windows.
  119.  12. Virus Handling under OS/2.
  120.  13. Central Point Anti Virus Inoculation
  121.  14. The Antivirus TSR (Terminate and Stay Resident).
  122.  15. Procedures to Use if Virus Activity is Suspected.
  123.  16. Practicing InVircible, the AV Practice Lab (AVPL).
  124.  
  125.  Appendices
  126.  
  127.  Appendix A. - LAN Protection
  128.  
  129.  
  130.  Preface
  131.  
  132.  This manual provides the essential information for the installation and
  133.  use of InVircible. The InVircible software is user friendly, intuitive
  134.  and will provide long-lasting virus protection. After installation
  135.  InVircible functions unobtrusively without the need for ongoing user
  136.  actions.
  137.  
  138.  The key component of InVircible is a rule-based Expert System that
  139.  insures that most of virus attacks will be detected and removed from
  140.  your IBM PC-class DOS system. For those situations where complex or
  141.  compound virus attacks are detected, InVircible's utilities and this
  142.  manual's guidelines provide for a user directed thoroughly complete
  143.  restoration. In addition to background and program documentation, this
  144.  manual provides guidelines for minimizing ongoing threats to the
  145.  well-being of your PC's health. InVircible may be installed and used
  146.  with assistance only from the on-line user help, so many InVircible
  147.  users operate without the manual. A Quick Start section in this manual
  148.  guides the user who prefers to install immediately and re view the
  149.  manual in detail later.
  150.  
  151.  InVircible's basic features, the integrity checker, the correlation
  152.  scanner, the virus scanner and the ResQdisk program are accessed via a
  153.  menu using the IVMENU command. Command line execution is also
  154.  available. Advanced features are integral components of the InVircible
  155.  package; those advanced features are used rarely during day-to day
  156.  operation in defense against simple virus attacks. Since most virus
  157.  attacks are uncomplicated solo attacks of your system, InVircible's
  158.  basic features will give you excellent ongoing protection. The advanced
  159.  features are always available for simple or complex virus attacks and
  160.  provide you with leading edge technology capabilities to eradicate even
  161.  the most clever and troublesome viruses.
  162.  
  163.  InVircible provides a layered approach to protection from computer
  164.  viruses. The first layer are the InVircible automatic detection and
  165.  recovery features, embedded in IVINIT, which provides InVircible with
  166.  extreme resistance to being bypassed or attacked by viruses. The second
  167.  layer is the IVB integrity checker and restorer that secures your
  168.  files, detects and eradicates new viruses (especially the
  169.  "unrecoverable" viruses) and recovers the files that become infected
  170.  with one or more viruses. The third layer are IVX and IVSCAN, the
  171.  correlation and virus scanners for tracing down infected files and for
  172.  the elimination of common or unknown viruses.
  173.  
  174.  In support of the above are: IVTEST, a module that checks computer
  175.  memory for viral activity in real time, and ResQdisk, an advanced tool
  176.  for inspecting and recovering the critical boot sectors and data of
  177.  your hard disk.
  178.  
  179.  InVircible avoids common problems of other anti-virus software.
  180.  InVircible programs recover themselves in case they become infected,
  181.  even from stealthy viruses. InVircible does not allow a "fast infector"
  182.  virus to "piggyback" its scanners and to infect an entire hard disk
  183.  drive. InVircible utilize an efficient virus activity probe instead of
  184.  memory resident (TSR - terminate and stay resident) component in its
  185.  protection scheme.
  186.  
  187.  InVircible allows you to automatically recover from virus attacks; or
  188.  you may prefer to manually guide the recovery.
  189.  
  190.  
  191.  Quick Start Instructions
  192.  
  193.  Insert the InVircible diskette into the A: or B: floppy drive.
  194.  
  195.         Type A: or B: at the command prompt line.
  196.         Type INSTALL/FAST to start the quick installation procedure.
  197.  
  198.  The InVircible INSTALL first examines your system for in- memory viral
  199.  activity and infected hard disk drive boot areas and files. After these
  200.  initial tests, InVircible then installs itself on your system to a
  201.  default directory. If you prefer to install InVircible with parameters
  202.  other than the default then use the plain INSTALL command. During the
  203.  installation phase, all files on hard disk drive partitions will be
  204.  scanned, then "secured" by IVB, the integrity checker. Although
  205.  InVircible's functions are designed to be exceptionally fast, this
  206.  initial scanning and securing of a large number of files may take a few
  207.  minutes, so please be patient! Whenever a choice is provided, the
  208.  default selection is the recommended choice. We encourage you to
  209.  configure your system so that IVTEST, the real time viral activity
  210.  checker, is activated when you invoke a frequently used batch (BAT)
  211.  file (see Sections 4).
  212.  
  213.  NOTE: Preparation of a Rescue Diskette (Section 2) is critical for
  214.  effective recovery from boot block and complex viral attacks. The
  215.  preparation is needed before a virus infection may occur.
  216.  
  217.  Using InVircible
  218.  
  219.  Type IVMENU to access the user-friendly menu. Choose your selection by
  220.  using the keyboard or a mouse.
  221.  
  222.  The Integrity Test option activates IVB, the integrity checker. Choose
  223.  the Virus Scanner option to activate IVSCAN, the virus scanner. The F1
  224.  key provides access to the extensive, on-line, interactive hypertext
  225.  manual. You may exit InVircible by pressing the F10 key, Alt+X, Alt+Q
  226.  or clicking the mouse on the 'quit' field from the main panel. The
  227.  escape key (Esc) returns you to the previous IVMENU panel.
  228.  
  229.  After IVB is selected, you choose the drive partition and directories
  230.  to examine and whether to "validate", "secure", or "restore" files.
  231.  When selecting IVSCAN, you choose the drive partition to scan, the
  232.  directory (or directories) to examine, and whether to "scan" viruses or
  233.  "remove" them also. For IVB and IVSCAN, it is usually best to utilize
  234.  the default choice first, i.e., either "validating" or "scanning".
  235.  These advisory modes notify you of suspicious activity. You may then
  236.  make an informed decision regarding the appropriate action to take.
  237.  
  238.  
  239.  Suggested Protection Routine
  240.  
  241.  IVINIT will check on any initialization of the computer that the boot
  242.  block and operating system are intact.
  243.  
  244.  IVB will automatically run a daily check of all your executable files
  245.  in all local partitions on the hard drive. IVB is the primary tool for
  246.  monitoring the integrity of files and for their recovery in the event
  247.  of a virus infection. IVB will report changes in executable files. Some
  248.  changes in executable files are expected if you generate your own
  249.  applications and program executable filenames are reused. IVB will
  250.  normally prompt and suggest the renewal of the database file in a
  251.  directory, in case the changes are a new version of a program. Yet,
  252.  software developers will need to be aware when alterations are
  253.  legitimate and when they are not. User generated executable should be
  254.  secured immediately with IVB. When installing new software packages,
  255.  scan the diskettes with IVSCAN before installation. After installation
  256.  run IVB on all directories to secure any added executable file.
  257.  
  258.  Application programs such as DOS or Windows do not change normally
  259.  unless they have been upgraded or purposely changed such as adding or
  260.  deleting an entry to the SETVER table. A consistent change pattern
  261.  reported by IVB indicates a viral infection. IVB provides this
  262.  information both on screen and in a report file (IVB.RPT) placed in the
  263.  partition root directory. Print this file to help assess the situation
  264.  if you suspect virus activity. A report of only a single file having
  265.  become modified requires you to proceed carefully ! Viruses rarely
  266.  infect only one file, so an indication of a single modified file may
  267.  not necessarily indicate the presence of a virus.
  268.  
  269.  When a genuine infection is found, try IVSCAN first, to discard the
  270.  possibility of an infection by a common virus.
  271.  
  272.  Viruses unknown to IVSCAN may be removed using IVB, provided the
  273.  programs were secured before becoming infected.
  274.  
  275.  New viruses, unknown to IVSCAN or where no securing signatures exist,
  276.  can be found using IVX. The suspected files can have their extension
  277.  name be renamed to a non- executable one and the files can then be
  278.  replaced from backup.
  279.  
  280.  
  281.  1. Introduction
  282.  
  283.  1.1. What are Computer Viruses?
  284.  
  285.  Computer viruses are sophisticated computer code written by imaginative
  286.  programmers, having little respect to other's people work. Their
  287.  motives are many, but the indisputable fact is that there exist already
  288.  thousands of them, and several new ones are written daily! Viruses have
  289.  to be purposely designed and written, they don't just appear from
  290.  nowhere. However, to be a virus, there is one characteristic this
  291.  program must have: It must replicate (or copy) itself so that it can
  292.  spread. In order to assure its continuous spreading, the virus program
  293.  must take control of the program's execution, either if it is a
  294.  bootstrap program or an application file.
  295.  
  296.  Computer viruses are passed the same ways we obtain software; by
  297.  copying from friends, from bulletin board systems, with newly purchased
  298.  PCs and even in vacuum wrapped new software.
  299.  
  300.  1.1.1 Categories of Computer Virus
  301.  
  302.  There has been much discussion regarding computer viruses and elaborate
  303.  technical names are being used, such as stealthy, polymorphic,
  304.  multipartite, spawning and self- encrypting. In reality, there are only
  305.  two general virus categories:
  306.  
  307.         (1) Viruses that infect through the boot sector or partition
  308.             table (MBS);
  309.         (2) Viruses that infect through files;
  310.  
  311.  All encountered viruses fall into one of the above two categories or
  312.  both. There are multipartite viruses that combine the properties of the
  313.  two categories (boot and file). Such are the Junkie, Natas and Tequila
  314.  viruses.
  315.  
  316.  A new variant of file viruses emerged in late 1991. It manipulates the
  317.  file allocation table (FAT) in order to spread. We will call them FAT
  318.  manipulators or cluster infectors.
  319.  
  320.  For the sake of reference, below is a quick definition of terms that
  321.  are used to describe viruses and techniques employed by viruses:
  322.  
  323.  1.1.2 File Viruses
  324.  
  325.  A file infector attacks executable program files, having a COM or EXE
  326.  extension name. File infectors may corrupt non- executable files as
  327.  well but they cannot spread this way, unless the affected file is
  328.  renamed to an executable filename and executed.
  329.  
  330.  Many file viruses are memory resident (TSR). After an infected file is
  331.  executed, they will remain resident in the computer's memory until the
  332.  computer is turned off. While in memory they will continue to infect
  333.  other programs and may interfere with normal operations. If the
  334.  computer is turned off they will lie dormant until an infected file is
  335.  executed and then load themselves back into memory again until the next
  336.  time the computer is turned off.
  337.  
  338.  
  339.  1.1.3 Boot Viruses
  340.  
  341.  Boot viruses attack boot records and master boot records (MBR,
  342.  sometimes referred as the partition sector). When the computer is
  343.  turned on, it runs a couple of tiny program from the hard disk, first
  344.  the partition bootstrap and then the boot loader, to ready itself for
  345.  work. In case of a boot infection, one of these programs may simply be
  346.  a virus. Boot viruses will remain active in memory while the computer
  347.  is on.     During this time they will infect write enabled floppies
  348.  that the computer accesses.
  349.  
  350.  
  351.  1.1.3 Multipartite Viruses (boot and file infectors)
  352.  
  353.  Multipartite viruses infect both executable files and boot- partition
  354.  sectors. When the computer is turned on the virus will be active and
  355.  infect additional programs that are executed. Multipartite viruses are
  356.  sometimes referred to as 'droppers', meaning that when an infected file
  357.  is executed, it will drop its own boot program into the hard drive boot
  358.  area.
  359.  
  360.  
  361.  1.1.4 FAT Manipulators (file infectors)
  362.  
  363.  The FAT manipulators are basically file infectors, with a unique
  364.  infection mechanism. FAT manipulators are inherently stealth viruses
  365.  because they hide the increase in file length, although the virus code
  366.  is actually appended to the file. The way it is done is by inserting
  367.  the extra clusters in the file's clusters chain in the FAT. Two well
  368.  known such viruses are Dir-2 and 1963 (Necropolis). FAT manipulators
  369.  are also excellent piggy-backers.
  370.  
  371.  1.1.5 Techniques used by Computer Viruses.
  372.  
  373.  1.1.5.1 Stealth
  374.  
  375.  Stealth viruses are so named because they actively seek to hide
  376.  themselves to prevent detection. Stealth viruses that infect files will
  377.  subtract their own size (in bytes) from the infected host file at any
  378.  time that a directory (DIR) command is executed. The Whale virus is a
  379.  good example of this. When it infects a file it adds 9216 bytes (and
  380.  some mutations may reach even 16 Kb in length) to the file size (a copy
  381.  of itself). If the DIR command is issued, it subtracts the virus length
  382.  (9216 bytes) from the displayed host file length. Thus it effectively
  383.  hides itself from the computer operator eye and from the operating
  384.  system.
  385.  
  386.  Some boot viruses use stealth (spoofing) techniques too. Stealth boot
  387.  viruses will deceit editing tools such as Norton's Disk Editor. Example
  388.  of stealth boot viri are Monkey and Noint. Natas and Gingerbread Man
  389.  are multipartite viruses that use boot spoofing too.
  390.  
  391.  1.1.5.2 Encryption
  392.  
  393.  Most of modern viruses use encryption to evade detection by scanners.
  394.  An encrypted virus has a very short common encryptor (from as few as 3
  395.  bytes, to a couple of dozen bytes) and the rest of the virus code is
  396.  encrypted and differs from copy to copy of the virus. The detection of
  397.  encrypted viruses cause high false alarm rates due to the ambiguity in
  398.  the detection of the short common string.
  399.  
  400.  1.1.5.3 Mutation Engine or Polymorphism
  401.  
  402.  Polymorphic viruses are a higher order of encrypted viruses. In
  403.  addition to encryption, they use a "mutations generator" that scrambles
  404.  the encryption too. A polymorphic virus mutates itself, so that each
  405.  occurrence is totally different from the one before. This creates huge
  406.  difficulties for anti- virus scanners, because they cannot look for a
  407.  'known' virus signature. Polymorphic viruses have rendered scanners
  408.  effectively useless since they cannot be removed by an algorithmic
  409.  approach.
  410.  
  411.  1.1.5.4 Spawning (or Companion) Viruses.
  412.  
  413.  Companion viruses take advantage of the precedence DOS gives to COM
  414.  over EXE files in the order of execution. If there are two files
  415.  bearing the same name, one with a COM extension name and the other with
  416.  an EXE extension, then DOS will execute the COM file first. A companion
  417.  virus is basically a Trojan that "infects" EXE files by spawning itself
  418.  into a companion COM file, bearing the same name as the EXE file.
  419.  Sometimes the companion virus file will have its attribute set to
  420.  'hidden', to avoid its detection by the DIR command.
  421.  
  422.  1.2 InVircible's Main Features
  423.  
  424.  *  It handles both known and unknown computer viruses.
  425.  *  It is extremely fast, professional and easy to operate;
  426.  *  Does not require any costly updates;
  427.  *  Is self-sufficient and provides real time recovery from new or
  428.     unknown viruses. Does not need outside assistance;
  429.  *  Has Extremely low false-alarm or 'false positives', with the highest
  430.     probability of 'true positives' detection;
  431.  *  Uses a unique unobtrusive file protection and restoration scheme.
  432.  *  Has an automatically updating distributed database for restoration
  433.     of files.
  434.  *  Has redundant and user-defined security features.
  435.  *  Uses a unique generic virus behavior probe and sampler.
  436.  *  Is not memory-resident and does not adversely affect computer
  437.     performance.
  438.  *  Uses unique programs that automatically check themselves for, and
  439.     restore themselves from virus infection.
  440.  *  Is friendly and uses a menu-driven user interface.
  441.  *  Features an interactive installation utility.
  442.  *  Is compatible with all major LANs (Local Area Networks).
  443.  *  Has an indispensable toolbox for computer security experts and
  444.     advanced users.
  445.  *  Has generic procedures for full recovery from the Dir-2 and 1963 FAT
  446.     and directory manipulators.
  447.  *  Utilizes sabotage-resistant protection designed to avoid both human-
  448.     and virus-based deception.
  449.  *  Is piggybacking resistant to prevent InVircible from be coming a
  450.     virus carrier.
  451.  *  Has extensive context-sensitive hypertext on-line help; and
  452.  *  Is financially affordable;
  453.  
  454.  
  455.  2. Getting Started
  456.  
  457.  2.1 Working from the InVircible Floppy.
  458.  
  459.  InVircible is to be used from the hard disk drive. Yet, it can be used
  460.  from the original distribution floppy. Boot the computer from either a
  461.  DOS diskette or from the hard disk. Put the original diskette in one of
  462.  the floppy drives and run IVMENU from the InVircible diskette. For
  463.  reading the on- line hypertext manual either run IVHELP or use the F1
  464.  key when in IVMENU.
  465.  
  466.  2.2 Preparation of the Rescue Diskette.
  467.  
  468.  The Rescue Diskette is a bootable floppy, containing the necessary
  469.  InVircible programs, the hard-disk's boot-areas image files, the data
  470.  stored in the CMOS, a copy of your AUTOEXEC.BAT and CONFIG.SYS and some
  471.  useful DOS files such as FDISK, SYS, and UNFORMAT. It enables to
  472.  recover the boot areas of a given hard-disk, the CMOS settings, as well
  473.  as the recovery of files in case of infection. The Rescue Diskette is
  474.  fully operable only on a computer that has the registration key
  475.  installed on the hard disk.
  476.  
  477.  Install InVircible normally to the hard disk and reboot the computer to
  478.  make the installation effective. Insert a formatted diskette into drive
  479.  A and run INSTALL/R. First, the system and InVircible files will be
  480.  transferred to the diskette, to make it bootable. Then, the boot areas
  481.  of your hard-drive will be backed-up to the diskette. Write-protect the
  482.  diskette.
  483.  
  484.  Partitioning device drivers (e.g. SpeedStor), disk- compression
  485.  (Stacker, SuperStor, DoubleSpace), password drivers etc., required to
  486.  recognize partitions or drives at booting time, should be installed
  487.  onto the Rescue Diskette. DoubleSpace, Stacker and Ontrack's Disk
  488.  Manager are all taken care of by InVircible.
  489.  
  490.  In other cases, copy the driver to the rescue-disk and edit its
  491.  CONFIG.SYS file by an ASCII editor. It should contain an appropriate
  492.  DEVICE line for each driver to be loaded at booting time.
  493.  
  494.  There is no point in preparing a Rescue Diskette for a computer without
  495.  a hard disk. The Rescue Diskette is individual to the specific
  496.  hard-disk for which it was prepared. Rescue Diskettes should never be
  497.  swapped between computers.
  498.  
  499.  
  500.  3. Using the Main Menu (IVMENU).
  501.  
  502.  IVMENU may be started in different modes by using the command line
  503.  options. By default IVMENU will start in the Integrity Check mode, on
  504.  the current drive. IVMENU's command line syntax is:
  505.  
  506.                         IVMENU [/switch] [drive:]
  507.         Switches:
  508.  
  509.         /V to start in the Virus Scan mode,
  510.         /R to start the ResQdisk boot block maintenance utility.
  511.  
  512.  The "drive" option will home IVMENU to a different than the current
  513.  drive at startup. The switches and the drive option may be used in
  514.  combination in any order.
  515.  
  516.  There are several ways to change options and modes with IVMENU, just
  517.  use the keyboard or the mouse anyway you like. Any "sensible" action
  518.  will respond accordingly.
  519.  
  520.  
  521.  3.1 IVMENU Special Keys.
  522.  
  523.  Alt + key combinations: the Alt key combined with either I, H, R or V
  524.  will switch to the Integrity Check, Hyper- Correlator, ResQdisk or
  525.  Virus Scanner respectively.
  526.  
  527.  Ctrl + key combination: the Ctrl key, when combined with a character
  528.  from A to Z will change the current drive to the one selected, if
  529.  available.
  530.  
  531.  Alt + G shortcut control: the shortcut hot-key is labeled "Go" when a
  532.  mouse is found or "Alt + G" when the mouse is inactive. The shortcut
  533.  control may be used to proceed with the selected mode without further
  534.  selections. Press Alt+G or click the mouse on the green "traffic light"
  535.  at the top center of IVMENU's display.
  536.  
  537.  3.2  The IVMENU Caution Panel.
  538.  
  539.  The CAUTION PANEL is at the right-hand side of IVMENU's main screen. It
  540.  displays various parameters on InVircible settings as well as selected
  541.  warnings, related to possible virus problems.
  542.  
  543.  The first two entries are dedicated to memory stealing alert. In case
  544.  DOS reports less than the expected memory, a message indicating the
  545.  number of missing kilobytes will pop up. The message will prompt for
  546.  confirmation to set the alert threshold to the difference detected.
  547.  Once set, IVMENU and the InVircible programs will ignore missing
  548.  memory, if equal to the set threshold. The threshold is reset
  549.  automatically to zero when IVMENU detects more DOS memory than the
  550.  current threshold setting.
  551.  
  552.  A Low memory message will be displayed in case missing memory is
  553.  detected and the user didn't confirm the setting of the threshold.
  554.  There are instances when less than 640 Kbytes of DOS base memory is
  555.  normal, such as with certain settings of the setup or in certain
  556.  compatibles, especially when booted from a diskette (Acer, some Dell
  557.  models, HP etc.).
  558.  
  559.  The third entry is the current database file name. This filename may be
  560.  changed through IVMENU by selecting Rename from the Integrity Check
  561.  menu. IVMENU will prompt for a name, or ask to press Enter to reset to
  562.  the IVB.NTZ default filename. See also for "extra security" in the IVB
  563.  topic.
  564.  
  565.  The fourth entry indicates the available space in bytes on the target
  566.  drive. In case the available space on disk decreases, a Disk space
  567.  lost! message will come up, indicating the number of bytes "lost". In
  568.  case lost space is reported, one should be aware of the possibility of
  569.  virus piggybacking. IVB or IVSCAN will stop the scanning process in
  570.  case piggybacking is detected.
  571.  
  572.  The fifth entry indicates the frequency of the full disk Integrity
  573.  Check. If InVircible was properly installed, it should be either DAILY
  574.  or WEEKLY. If not, re-INSTALL InVircible as detailed elsewhere.
  575.  
  576.  The last entry checks for the registration status and will indicate
  577.  "full" or "detection only". The empty field at the bottom is reserved
  578.  for warning messages.
  579.  
  580.  
  581.  3.3 The Last IVB, IVSCAN or IVX Report.
  582.  
  583.  The last report generated by either IVB, IVSCAN or IVX can be viewed on
  584.  screen through IVMENU. Select the Last Report in the Integrity Check or
  585.  Virus Scan mode. The IVX report can be viewed in either modes by
  586.  pressing the X key and then Enter. The report files are written to the
  587.  target's root directory and named IVSCAN.RPT, IVB.RPT or IVX.RPT. The
  588.  report file can redirected to the printer by DOS command, either PRINT
  589.  filename or TYPE filename > PRN.
  590.  
  591.  4. InVircible Installation
  592.  
  593.  4.1 Installation to Hard-disk.
  594.  
  595.  Insert the InVircible diskette in drive A or B. Log-in to that drive.
  596.  Run INSTALL to begin the installation.
  597.  
  598.  The INSTALL program will prompt for the directory to install to. Type
  599.  the full pathname of the preferred location or just press Enter for the
  600.  default, when prompted.
  601.  
  602.  The Utilities sub-menu, has the following options:
  603.  
  604.      a. The Batches sub-menu. Enables the insertion/removal of the
  605.         IVTEST command to/from batch files in specified directories. The
  606.         installation of the IVTEST probe in batch files is optional.
  607.         IVTEST will be installed in its "quiet" mode. IVTEST messages
  608.         will be displayed only if suspect activity is detected.
  609.  
  610.      b. The Rescue-Disk sub-menu, for the preparation of the diskette.
  611.  
  612.      c. The On-line Registration sub-menu. Enables the on-line
  613.         registration of InVircible by telephone and credit card. Call
  614.         your local dealer for more details.
  615.  
  616.      d. The Key Installation/Removal sub-menu. Enables either the
  617.         installation or removal of the InVircible registration key
  618.         to/from the hard drive. The process is reversible.
  619.  
  620.  4.2 Installation To or From LAN Server.
  621.  
  622.  InVircible is a universal anti-virus, recommended for both single user
  623.  PCs as well as for all popular LAN brands.
  624.  
  625.  INSTALL enables the installation of InVircible to a file server or to a
  626.  workstation in a network. The default is installation to a single user
  627.  PC's hard disk.
  628.  
  629.  Select where to install InVircible (singe user PC - the default -, to
  630.  a file server, or to a workstation in a network) from the Install
  631.  sub-menu. Note that the installation (or removal) of the registration
  632.  key to the hard disk can be done from the original diskette only.
  633.  
  634.  InVircible may be installed to any chosen directory on the server. The
  635.  contents of the server should be secured by the LAN manager.
  636.  
  637.  All stations connected to the network and equipped with a hard-drive
  638.  need individual registration. The file server does not need the
  639.  installation of the registration key. Any workstation in the network
  640.  having a hard disk may be infected prior to logging-in to the network.
  641.  Therefore, any such station needs its own InVircible installation.
  642.  
  643.  For LAN administrators: It is possible to install InVircible to all
  644.  workstations, from the server. The IVLOGIN utility is provided with the
  645.  distribution floppy. IVLOGIN checks if there is a hard disk and whether
  646.  IV is installed on it. In case it is not, IV will be installed
  647.  automatically with its default parameters. Add the IVLOGIN command in the
  648.  LOGIN script, with the full pathname where the IVLOGIN.EXE file is
  649.  located. IVLOGIN must be in the same directory as the IV files.
  650.  
  651.  4.3 Installation Under OS/2.
  652.  
  653.  The InVircible INSTALL procedure must be run from a plain DOS
  654.  environment. If INSTALL is attempted from OS/2, a warning message will
  655.  request the user to boot from DOS and try again.
  656.  
  657.  4.4 Installation in the Sentry Mode.
  658.  
  659.  There are instances when only the detection and alerting functions of
  660.  InVircible's are needed. To install InVircible in the sentry mode
  661.  (detection only), just skip the key transfer step in the installation
  662.  procedure by running INSTALL/FAST or by leaving the write protect of
  663.  the InVircible diskette in the protect position. The retraction of the
  664.  registration key from the hard disk back to the diskette will also
  665.  switch InVircible to the sentry mode.
  666.  
  667.  The sentry mode is indicated by the "Detection only" label instead of
  668.  "Full Registration", in IVMENU's Caution Panel and in the upper left
  669.  corner of the program's panel.
  670.  
  671.  5. Recommended Anti-Virus Strategy
  672.  
  673.  5.1 In the Single User Environment.
  674.  
  675.  Install InVircible to the hard drive, as instructed above. The INSTALL
  676.  utility will edit the AUTOEXEC file, after prompting for permission,
  677.  and add the necessary commands for automatic tests to be run on the
  678.  computer initialization. None of the InVircible programs will load
  679.  itself and stay resident in memory. Once it completed its function, it
  680.  will unload and leave the maximum of available memory to the
  681.  applications.
  682.  
  683.  From now on, InVircible will detect and correct the most severe
  684.  problems right at initialization. These include partition or boot
  685.  sector tampering and certain operating system changes. Boot viruses
  686.  such as Michelangelo, Stoned and Monkey will simply be purged from the
  687.  disk immediately at startup.
  688.  
  689.  It some cases, InVircible may just alert, without correcting, on the
  690.  presence of a suspected activity in the computer. Such alert is
  691.  accompanied by a message describing the generic nature of the problem
  692.  and the recommended corrective action.
  693.  
  694.  On first booting at any given-date, IVB will scan through all the hard
  695.  disk local partitions. On successive initializations on the same date,
  696.  only the root directory will be scanned. Added programs will be
  697.  automatically secured on the daily scan. If weekly scans are preferred,
  698.  change the DAILY argument to WEEKLY, in the AUTOEXEC file.
  699.  
  700.  Read Only drives (CD ROM): CD drives cannot (and need not) be secured.
  701.  The INSTALL utility will normally detect ROM drives and disable their
  702.  daily check. In case it hasn't, just add a space and a dash at the end
  703.  of the daily command. For example, if D: is a CD drive, modify the
  704.  command as follows:
  705.  
  706.                         IVB C: DAILY -
  707.  
  708.  Make frequent data backups. Data should be backed-up at reasonable
  709.  intervals. Programs should be backed-up only once or kept preferably on
  710.  the original distribution disks.
  711.  
  712.  It is highly recommended to regularly run a FAT backup program, such as
  713.  MIRROR from DOS 5 or IMAGE from Norton Utilities, from the last line of
  714.  the AUTOEXEC.
  715.  
  716.  The InVircible system uses a unique virus-activity probe and sampler,
  717.  called IVTEST. Since the reliability of memory-resident activity
  718.  monitors is limited only to known viruses, and some of them are
  719.  obtrusive or risky, there is need to verify from time to time, that a
  720.  viral process is not spreading in the system. This is achieved by the
  721.  automatic running of IVTEST, from frequently used BATCH files. The
  722.  INSTALL utility will add the appropriate command into specified
  723.  directories.
  724.  
  725.  5.2 In a Network Environment.
  726.  
  727.  Any workstation equipped with a hard disk, should have its own
  728.  InVircible installation. The InVircible distribution diskette for LAN
  729.  installations has multiple registration keys, according to the number
  730.  of licensed users. The registration key should be installed only to
  731.  local hard disks, in workstations equipped with.
  732.  
  733.  It is recommended that the LAN manager run a daily IVB inspection of
  734.  selected directories of the server. This can be done by adding command
  735.  lines in the network schedule file or script. IVB returns an errorlevel
  736.  exit-code. Errorlevel 0 means no findings, and anything else may
  737.  indicate virus activity. Test for errorlevel 1 in batch or script files
  738.  for suspect activity alerting.
  739.  
  740.  It is normal to find modified files in users directories, especially if
  741.  they develop software. On the other hand, modified files with a
  742.  consistent change pattern should alert on the possibility of a virus in
  743.  the system. IVB will assess whether the changes may be a new version of
  744.  a former program. IVB will then prompt if to renew the database file
  745.  for that specific directory.
  746.  
  747.  5.3 In the Institutional Environment
  748.  
  749.  Most institutional installations involve combinations of single users
  750.  and network users, requiring an anti-virus plan that is a combination
  751.  of the preceding strategies. Many large institutions also have an
  752.  anti-virus policy requiring that virus related problems be dealt with
  753.  only by qualified personnel. In this situation the InVircible
  754.  registration key is not installed or is removed from systems not
  755.  authorized to deal with virus removal. Systems without InVircible keys
  756.  are still protected, but recovery of these systems from virus attacks
  757.  is performed only by qualified personnel with access to an InVircible
  758.  registered floppy.
  759.  
  760.  Especially useful in an institutional environment are IVX and ResQdisk
  761.  (see Sections 8 and 9). These utilities provide indispensable help to
  762.  the institute's computer security experts for the recovery of "lost"
  763.  hard drives and for tracking down sources of infection, especially of
  764.  new vi ruses.
  765.  
  766.  5.4 In Unattended Installations (e.g. Bulletin Board Systems - BBS).
  767.  
  768.  There are instances when the operation of a PC is unattended, such as
  769.  in bulletin board systems etc. The daily inspection of IVB may in such
  770.  cases pause the system, if the system was rebooted and IVB found
  771.  changes in programs, when compared to their store signatures. To bypass
  772.  the pause use the /nostop switch on IVB's command line in the AUTOEXEC,
  773.  as follows:
  774.  
  775.                      IVB C: DAILY /NOSTOP
  776.  
  777.  6. IVB - The File Protection & Restoration Program.
  778.  
  779.  IVB will secure, authenticate and restore executable programs from
  780.  virus infection and virus-like modifications, except for FAT/directory
  781.  manipulators (see Section 10).
  782.  
  783.  IVB takes a 66 byte "snapshot" (signature) of critical information from
  784.  each executable file and stores this information in each directory's
  785.  InVircible database. This process is called "securing". The information
  786.  is then used during "authentication" (also called "validation") to
  787.  determine whether a file is modified by a virus. The database is also
  788.  used to "restore" files that have been modified by viruses.
  789.  
  790.  Viruses are characterized by unique properties: They replicate into
  791.  other programs, they modify the host program and they normally affect
  792.  more than one program. All these anomalies are unmistakably detected by
  793.  IVB.
  794.  
  795.  Common viruses will usually increase the size of a file, while
  796.  Trojan-Horses typically decrease the size of a file by overwriting it.
  797.  If IVB detects that more than one file is "modified" or "changed in
  798.  size", then virus activity is indicated.
  799.  
  800.  A single modified file, or an inconsistent change pattern, may be a new
  801.  version of an existing program. IVB will usually detect a version
  802.  change and suggest to resecure the directory.
  803.  
  804.  IVB restores programs that have been secured. Prior to restoring files
  805.  with IVB, scan first with IVSCAN to assure that the virus is not of a
  806.  known type. Recovery with IVSCAN should be tried first, before
  807.  restoring with IVB. The IVB command-line syntax is:
  808.  
  809.               IVB [-] [drive:\directory] [/option]
  810.  
  811.  The default drive and directory are the current ones. The various
  812.  options are:
  813.  
  814.       none for authentication (the default),
  815.       /S for secure,
  816.       /R for restore,
  817.       /D for delete and
  818.       /V for the removal of the database files.
  819.  
  820.  Let IVMENU guide you through the options.
  821.  
  822.  The Delete option will erase files that have been decreased in size
  823.  (potential Trojans) or files that cannot be restored safely.
  824.  
  825.  The [-] switch (space followed by a hyphen) indicates to IVB to operate
  826.  on the specified directory only without continuing to any other
  827.  directory or sub-directory.
  828.  
  829.  IVB will automatically secure added files when run in the default mode.
  830.  The secure mode is to be used in case IVB indicates a modified file,
  831.  which is a replacement rather than a modified one. Use the single
  832.  directory switch to resecure a single directory by selecting it through
  833.  IVMENU.
  834.  
  835.  IVB is tamper-resistant and will replace the database file of a
  836.  particular file, if tampered with.
  837.  
  838.  IVB secures executable files (COM, EXE, SYS) only.
  839.  
  840.  Before attempting the recovery of a file by IVB you will be prompted
  841.  with three options: Restore, Skip or All (restore all).
  842.  
  843.  
  844.  6.1 The IVB Extra-Security Feature.
  845.  
  846.  IVB has an extra security feature which allows the user to define the
  847.  name of the database files. The default name is IVB.NTZ. This will
  848.  prevent the destruction or modification of the IVB database files by a
  849.  dedicated virus. It allows the user to define a unique database file
  850.  name, other than the default. To set a different name to the database
  851.  files use the Rename option from IVMENU's default. The database
  852.  filename in use is indicated in the Caution Panel of IVMENU.
  853.  
  854.  6.2 Off-line Backup of the InVircible Database.
  855.  
  856.  There are instances when an off-line backup of the database- files tree
  857.  is desirable. Making such a backup is easy using the Off-line Backup
  858.  option. Use IVMENU to produce an exact replica of the database file's
  859.  tree on a previously formatted diskette in either floppy drive A: or
  860.  B:. If necessary, the database files may be restored to their original
  861.  locations by the Restore option of the Off-line Backup mode from
  862.  IVMENU.
  863.  
  864.  A typical 200 Mbytes disk partition will require about 200 Kilobytes of
  865.  space for an off-line InVircible backup.
  866.  
  867.  Attention LAN managers: An off-line backup for a typical 1 Gbytes file
  868.  server can be contained on a single 1.44 Mbytes diskette.
  869.  
  870.  
  871.  7. IVX - The Correlation Scanner.
  872.  
  873.  IVX is a generic correlator, based on the comparison of files to a
  874.  sample known to be infected. This way, IVX detects all the files that
  875.  were infected by the same virus and can even trace down the source of
  876.  the infection. IVX is ideal for isolating new viruses, or disinfecting
  877.  a machine with no previous installation of InVircible on it.
  878.  
  879.  InVircible generates its own samples through IVINIT and IVTEST, either
  880.  or both Virusample and Vir-Code. A file designated by IVB as changed,
  881.  may also be used as a valid sample.
  882.  
  883.  IVX runs from either the command line or from IVMENU. The command line
  884.  syntax is:
  885.  
  886.        IVX [pathname of sample file] [drive:\directory to search]
  887.  
  888.  Wildcards (*.?) are allowed in the sample's pathname.
  889.  
  890.  The IVX report is displayed in a graphic format, after the correlator
  891.  completes its scan. You may also want to review the IVX report through
  892.  IVMENU.
  893.  
  894.  Suspected files may be renamed through IVX to non executable extension
  895.  names: COM to IVC and EXE to IVE. IVX will prompt before actually
  896.  renaming a file. The renamed files may be safely copied to a floppy and
  897.  sent or e-mailed to us for further analysis and evaluation.
  898.  
  899.  The detection threshold of IVX can be adjusted in a range from 1%, for
  900.  highly polymorphic viruses, to 100%. The default is set to 20% of
  901.  correlation.
  902.  
  903.  Tips for using IVX.
  904.  
  905.  The correlator is a powerful tool in the hands of a trained user and
  906.  its findings are usually conclusive from the very first run. Yet, you
  907.  should be aware that virus writers make great efforts to conceal their
  908.  virus' presence. Therefore, do not expect a perfect match, but rarely,
  909.  when using IVX with real viruses. The results of IVX should be regarded
  910.  as relative, i.e. the files with the higher correlation are the more
  911.  likely to be infected. Plain viruses may exhibit anything from 40% to
  912.  100% correlation to the sample, while highly polymorphic viruses may
  913.  have as low as 4%. The conclusive evidence is that non-infected files
  914.  are in even lower correlation with the sample.
  915.  
  916.  Before launching IVX, spot a few infected files that could be used as
  917.  samples. The easiest is to look for them in the DOS directory.
  918.  Frequently used files are usually the first victims of an infection.
  919.  Boot from a clean DOS floppy and run IVX from a write protected or IV
  920.  Armored floppy.
  921.  
  922.  When dealing with a virus that infects both COM and EXE files, prefer
  923.  an infected EXE file as the sample, as it contains more relevant
  924.  information than infected COM. The results will be more conclusive than
  925.  with a COM sample.
  926.  
  927.  Before renaming suspected files through IVX, try a few runs with
  928.  different detection thresholds. Review the report to chose the best
  929.  threshold. The best is when all infected files are captured and the
  930.  report contains no false positives. It's preferable to replace a few
  931.  extra files in case of doubt, than to risk reinfection.
  932.  
  933.  Examples:
  934.  
  935.  Legend: ▓▓--Statistics, ▒▒--Encryption, ░░--String.
  936.  
  937.  C:\JERUSALEM\
  938.  ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒░░░░░░░░                    60  CHKDSK.EXE
  939.  ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒░░░░░░░░                    60  EMM386.EXE
  940.  ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒░░░░░░░░                    60  EXPAND.EXE
  941.  ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒░░░░░░░░ 100 DISKCOMP.COM
  942.  ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒░░░░░░░░ 100 MODE.COM
  943.  ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒░░░░░░░░ 100 MORE.COM
  944.  
  945.  The first example is of the Jerusalem virus. It infects both COM and
  946.  EXE files. The sample used in this illustration is Virusample file,
  947.  created automatically by IVTEST. The report shows 100% correlation of
  948.  the COM files and 60% for EXE, since Jerusalem is a plain non-encrypted
  949.  virus. If we had used Vir-Code instead, the results would be 100%
  950.  correlation for EXE and 60% for COM, as Vir-Code is an EXE style
  951.  sample, while Virusample is usually a COM one. The threshold was set to
  952.  50%, to filter out false positives.
  953.  
  954.  C:\MALTESE\
  955.  ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒                            40  FORMAT.COM
  956.  ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒                            40  MODE.COM
  957.  ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒                            40  MORE.COM
  958.  ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒░░░░░░░░ 100 DELTREE.EXE
  959.  ▓▓▓▓▓▓▓▓▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒                    56  EXE2BIN.EXE
  960.  ▓▓▓▓▓▓▓▓▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒                    56  EXPAND.EXE
  961.  ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒        80  FC.EXE
  962.  
  963.  The second example was taken from Maltese Amoeba (alias Irish) and is
  964.  especially interesting. Irish is heavily encrypted, although it is not
  965.  considered as polymorphic. DELTREE.EXE is used as the sample. Note the
  966.  dispersion in the correlation factor. Note also that the largest common
  967.  correlation is contributed by encryption (the middle shading). As a
  968.  rule, encrypted viruses will show no contribution from string matching,
  969.  with most of the similarity due to encryption, and sometimes some
  970.  contribution due to statistical matching. The threshold was set to 30%
  971.  in this case.
  972.  
  973.  Practicing IVX.
  974.  
  975.  It may be worth to practice with IVX so that you know what to do when
  976.  the real thing happens. You may use IVX to trace down files that were
  977.  processed in the same way. For example, all InVircible files, except
  978.  IVHELP, were processed by LZEXE runtime compression. Try the following:
  979.  
  980.                         IVX C:\IV\IVB.EXE C:\
  981.  
  982.  All the files that correlate higher than 65% are treated by LZEXE as
  983.  well. Now, if you correlate with IVHELP.EXE as the sample, IVX will
  984.  find programs that were processed by PKLITE. You will find a few of in
  985.  the DOS directory.
  986.  
  987.  Other compression schemes that can be used to practice IVX are: DIET
  988.  and Microsoft's ExePack. Correlate to \DOS\EXPAND.EXE for ExePack and
  989.  set the detection threshold to 70. For DIET, correlate to Frisk's
  990.  F-PROT.EXE (if you got a copy) and set the threshold to 50.
  991.  
  992.  
  993.  8. ResQdisk - The Boot-Areas and CMOS Maintenance Program.
  994.  
  995.  ResQdisk is a compact yet extremely powerful utility capable of
  996.  repairing damage to the hard disk partition or boot sector, removing
  997.  known and unknown partition or boot viruses, restoring self booting
  998.  capability to hard disks and regaining access to "lost" hard disks.
  999.  
  1000.  ResQdisk deals uniquely with hard disks drives, not with floppies.
  1001.  
  1002.  Disks are organized in sectors, which are 512 bytes data storage units.
  1003.  Any DOS hard drive has two such vital sectors: the master boot sector
  1004.  (sometimes referred to as the partition table) and the boot sector.
  1005.  Floppies have only a boot sector. These sectors are favorite targets
  1006.  for computer viruses, since they contain tiny programs that load first
  1007.  at booting time. A damaged or missing sector will return an "invalid
  1008.  drive specification" message, fail to boot, deny access to the hard
  1009.  drive or simply read trash from the disk.
  1010.  
  1011.  For maximum safety, the boot area images are written to the Rescue
  1012.  Diskette, since an inaccessible disk will deny access to the backup
  1013.  written to itself. ResQdisk's options are displayed on the menu bar, at
  1014.  the screen's bottom. Press F1 or "/" to see more options.
  1015.  
  1016.  The F1-F2 key sequence will backup the boot areas and the F1- F3
  1017.  sequence will restore from backup images to disk. Each sector can be
  1018.  individually backed up or restored by shifting to the desired sector on
  1019.  screen (use the cursor direction keys) and pressing either B for backup
  1020.  or R for restore.
  1021.  
  1022.  Every disk has a unique partition and boot sector. Do not attempt to
  1023.  swap or copy boot areas between hard-disks. This might end up with an
  1024.  unreadable contents of the transplant's receptor.
  1025.  
  1026.  8.1 Reconstruction of the Boot Block.
  1027.  
  1028.  ResQdisk has special routines for the reconstruction of the hard disk
  1029.  partition or boot sector, in case they have been damaged or cannot be
  1030.  recovered. For example, incidentally booting a disk which is infected
  1031.  with Stoned with a floppy infected by Michelangelo will not boot
  1032.  anymore by itself, although it can be booted from a DOS floppy.
  1033.  Attempting to restore the partition with the FDISK command may end up
  1034.  with the complete loss of the whole disk content.
  1035.  
  1036.  ResQdisk makes it easy; all that is needed is the following keys
  1037.  sequence:
  1038.  
  1039.              Press the 'Home' key, then F1, then F4
  1040.  
  1041.  Tampering with the boot sector is corrected by the sequence:
  1042.  
  1043.                      Left arrow, F1, F4
  1044.  
  1045.  8.2 ResQdisk's Special Functions.
  1046.  
  1047.  It may happen that the disk setup parameters stored in the CMOS become
  1048.  invalid because of a weak battery, a setup error and sometimes even bad
  1049.  software. If this happens then reboot the computer from the rescue
  1050.  diskette and press <Enter> when IVMENU finished loading into memory.
  1051.  Answer yes to the query "Attempt to restore the CMOS data?". The
  1052.  computer will then automatically reboot with the restored CMOS
  1053.  parameters.
  1054.  
  1055.  To see ResQdisk special functions menu press the "/" (slash) key.
  1056.  
  1057.  Warning! ResQdisk should not be used on disks that have a boot area
  1058.  password or access control device installed on them. These devices are
  1059.  highly susceptible to cause total loss of the whole disk content. As a
  1060.  rule of thumb: If a hard disk can be accessed after booting from a DOS
  1061.  floppy, then the partition refresh procedure may be used safely.
  1062.  
  1063.  8.3 ResQdisk's Setup Utility.
  1064.  
  1065.  ResQdisk has a built-in setup calculator. This may be especially useful
  1066.  with IDE hard drives, in case the CMOS data was erased or nullified and
  1067.  there is no available data on the drive parameters. All that is needed
  1068.  is to select a random disk type from the setup table, boot from a DOS
  1069.  floppy and run ResQdisk. The F5 function key will identify the
  1070.  manufacturer's parameters of the hard disk. All that is needed now is
  1071.  to set the CMOS data to the correct type and restart the computer.
  1072.  
  1073.  ResQdisk can also be used to regain access to an inaccessible hard
  1074.  drive, whether either the partition sector or the boot sector was
  1075.  damaged. ResQdisk will indicate "Press Ctrl F1" or "Press Ctrl F2" to
  1076.  rebuild the partition or the boot sector respectively.
  1077.  
  1078.  9. IVSCAN - The Virus Detection and Removal Scanner.
  1079.  
  1080.  While disinfecting a computer, with IVSCAN or else, the user must be
  1081.  aware of the possibility that a virus might be active in the computer's
  1082.  memory (memory-resident). Since a virus in memory has taken control of
  1083.  the computer, a general rule is to reboot an infected computer from the
  1084.  write- protected Rescue Diskette, or from a clean write-protected DOS
  1085.  diskette. The disinfection of a hard-disk must be per formed only from
  1086.  the Rescue Diskette and not from the suspected drive itself, unless
  1087.  InVircible's programs specifically recommend execution in an infected
  1088.  environment (e.g. Inverse Piggybacking).
  1089.  
  1090.  Detection of, and disinfection from known and common viruses is done by
  1091.  IVSCAN. The program is activated via IVMENU or directly from the
  1092.  command line. The command line syntax is:
  1093.  
  1094.               IVSCAN [-] [where and what to scan] [/Option]
  1095.  
  1096.  Parameters in [ ] are optional. If no option is chosen IVSCAN will
  1097.  detect viruses without removing them (the default). The default scan
  1098.  path are the current directory and its sub-directories. The use of
  1099.  wildcards (*,?) is allowed in specifying where and what to scan for.
  1100.  
  1101.  The options are:
  1102.  
  1103.           /R to restore the file (if it can),
  1104.           /D to delete infected files that IVSCAN cannot recover,
  1105.           /B to recover or replace a suspected boot sector in floppies,
  1106.              or MBR on hard drive.
  1107.           /EX to scan executable files only.
  1108.  
  1109.  The [-] parameter will limit IVSCAN to process the specified directory
  1110.  only.
  1111.  
  1112.  Examples: To scan the entire C: partition for viruses in the Detection-
  1113.  Only mode type:
  1114.                            IVSCAN C:\
  1115.  
  1116.  To use IVSCAN for detecting and eliminating viruses automatically only
  1117.  from COM files in the DOS directory, type:
  1118.  
  1119.                     IVSCAN + C:\DOS\*.COM /R -
  1120.  
  1121.  The space before the hyphen is required. If the hyphen is not used,
  1122.  this command will cause IVSCAN to begin at the specified directory and
  1123.  scan all subsequent sub-directories.
  1124.  
  1125.  If IVSCAN indicates "use IVB to restore" and the affected files were
  1126.  properly secured, then restore them with IVB (see Section 6). Use the
  1127.  Delete option as a last resort. A list of infected, deleted and
  1128.  restored files will be written to a IVSCAN.RPT file in the root
  1129.  directory of the processed drive, to help you replace the deleted
  1130.  files.
  1131.  
  1132.  Before attempting the recovery of a file IVSCAN will prompt you with
  1133.  three options: Recover, Skip or All (recover all).
  1134.  
  1135.  9.1  Removal of Generic Boot Viruses.
  1136.  
  1137.  Boot viruses are transferred from one computer to another by
  1138.  accidentally booting from an infected floppy (the infected diskette is
  1139.  left in drive A and the computer is rebooted), even if the floppy is
  1140.  not bootable, just infected! IVSCAN provides for the replacement of the
  1141.  boot sector in floppies with a standard DOS boot sector. The same
  1142.  procedure will remove generic boot infectors and even restore
  1143.  readability to 3.5" floppies that were hit by boot infectors such as
  1144.  Michelangelo. Just type:
  1145.  
  1146.                        IVSCAN drive: /B
  1147.  
  1148.  IVSCAN restores files infected by viruses included in its repertoire.
  1149.  For infectors unknown to IVSCAN use IVB.
  1150.  
  1151.  
  1152.  10. A Primer to Generic and Special Methods.
  1153.  
  1154.  Generic techniques can cure damage from groups of viruses such as
  1155.  boot-block infectors, stealthy file infectors and FAT manipulators.
  1156.  
  1157.  First, assess the type of infection by its symptoms, then test the
  1158.  suggested method on a sample diskette or directory. If successful,
  1159.  apply the selected technique onto the entire infected disk.
  1160.  
  1161.  
  1162.  10.1 Generic Method Selection
  1163.  
  1164.  As a rule, viruses always disclose there presence sooner or later.
  1165.  InVircible provides alerts when sensing various effects that are
  1166.  unmistakably related to computer viruses. Among InVircible's messages,
  1167.  the following are of special interest:
  1168.  
  1169.  (1)  "... Kbytes are missing from total available memory."
  1170.  (2)  "A stealthy virus is active in system."
  1171.  (3)  "File size changed by 0 (zero!) bytes ... "
  1172.  (4)  "Free disk space decreased by ... bytes, program halted!"
  1173.  (5)  "Partition (or boot) sector is faked!" (6)"The disk is infected by
  1174.        a boot infector!"
  1175.  
  1176.  Message (1) indicates "memory stealing", attributed mostly to the
  1177.  presence of a boot or partition infector. Certain file infectors do the
  1178.  same, and this possibility should be first discarded. Also, some
  1179.  programs such as DesqView, or certain BIOSes (PS, Dell, Acer and some
  1180.  laptops) cause the same without being related to virus activity.
  1181.  
  1182.  Message (2) or (3) indicate that a stealthy virus is active in the
  1183.  system.
  1184.  
  1185.  Message (4) indicates that a piggybacking process was detected and the
  1186.  search was halted to prevent further spreading of the virus.
  1187.  
  1188.  Message (5) indicates the presence of a stealth virus in one of the
  1189.  boot area sectors. Message (6) will be displayed when an unknown boot
  1190.  infector is found in one of the boot areas of the hard disk or of a
  1191.  floppy.
  1192.  
  1193.  In case the virus is common, InVircible will recommend on the
  1194.  corrective action. If not, then proceed as follows.
  1195.  
  1196.  It is recommended that less experienced users ask for assistance or
  1197.  leave the following procedures to qualified personnel, since dealing
  1198.  with smart viruses requires training and inexperienced users may do
  1199.  more harm than good.
  1200.  
  1201.     For the expert user.
  1202.  
  1203.     If one or more of the above messages are returned, then proceed with
  1204.     the following tests.
  1205.  
  1206.     Run IVB in its default mode with the virus in memory and watch if
  1207.     "modified files" are reported. In case such files are reported with
  1208.     the virus in memory, the virus is not a perfect stealthy one and
  1209.     cannot be restored by the Inverse Piggybacking or by the Integrity
  1210.     Interrogation generic methods.
  1211.  
  1212.     Next, boot from the Rescue Diskette and run IVSCAN to eliminate the
  1213.     possibility of a common infector. In case that IVSCAN reports the
  1214.     possibility of an unknown boot or partition infector, then proceed
  1215.     with the generic boot- block recovery.
  1216.  
  1217.     Non-perfect stealthy viruses can be recovered by IVB if the disk
  1218.     contents was previously secured.
  1219.  
  1220.     If the virus is a perfect stealthy (only), select either the Virus
  1221.     Interrogation technique or the Inverse Piggy- backing. Always try
  1222.     first on a floppy, which is the best technique to use for a
  1223.     particular virus.
  1224.  
  1225.     Beware of FAT manipulators! Run CHKDSK on the damaged unit, without
  1226.     the /F switch, when booted from a clean DOS diskette. Watch if file
  1227.     allocation error or cross-linking of executable files is reported.
  1228.     If yes, this may be the doing of a FAT manipulating virus.
  1229.  
  1230.     Do not attempt repair with disk fixing utilities if infected by a
  1231.     FAT manipulator. Any such attempt will end in massive and
  1232.     irreversible damage.
  1233.  
  1234.  In all cases, it is advised to test the selected method on a sample
  1235.  diskette and if successful, to apply it to the infected units.
  1236.  
  1237.  
  1238.  10.2 Generic Boot-Block Recovery
  1239.  
  1240.  InVircible and DOS provide for the recovery of both the Master Boot
  1241.  Sector, also known as the partition table sector, and the plain Boot
  1242.  Sector. Both sectors are found only on hard disks, while floppies have
  1243.  only a boot-sector.
  1244.  
  1245.  Floppies:
  1246.  
  1247.  IVSCAN provides for the recovery of a large spectrum of known and
  1248.  generic boot infectors, and will suggest the replacement of the sector
  1249.  with a standard DOS 5 one, in case a potential unknown infector is
  1250.  found. Hard Disk:
  1251.  
  1252.  The recovery should always start by inspecting the partition table
  1253.  first. Run ResQdisk to get acquainted with the look of both the
  1254.  master-boot-sector (MBS) and the system-boot-sector of your hard-drive.
  1255.  In case of boot-block tampering, boot from the Rescue Diskette and
  1256.  visually inspect both sectors by running ResQdisk. Some infectors such
  1257.  as FLIP will cause only minor changes, perceivable only to the expert
  1258.  observer, some as Stoned will show a message such as "Your PC is
  1259.  Stoned, Legalize Marijuana!". The restoration of both sectors is
  1260.  straightforward by ResQdisk .
  1261.  
  1262.  There are instances when there is no copy of the original sector to
  1263.  restore from, and no Rescue Diskette exists. For example, consecutive
  1264.  infections by Stoned and Michelangelo will not leave an original MBS.
  1265.  Master Boot Sectors can be restored by ResQdisk, provided the drive is
  1266.  accessible and readable after booting from a DOS disk in drive A.
  1267.  
  1268.  Enter the ResQdisk program and proceed with the F1 - F4 function keys
  1269.  sequence. This procedure is the equivalent of the DOS-5 undocumented
  1270.  command: FDISK/MBR.
  1271.  
  1272.  Caution! Do not use the ResQdisk F1-F4 procedure in the following
  1273.  cases:
  1274.  
  1275.  (1)   There is an active virus-prevention TSR in memory. Ad dressing
  1276.       the master-boot-sector may be diverted by such TSR and this may
  1277.       end in total loss of access to the hard- drive.
  1278.  (2)  The same applies for hard-disks with a software password
  1279.       installed. Uninstall the password prior to proceeding with this
  1280.       technique.
  1281.  (3)  Partitioning schemes other than DOS FDISK such as Disk Manager and
  1282.       SpeedStor are not suitable for this technique.
  1283.  
  1284.  As a safety precaution, first backup the boot-areas on the original
  1285.  InVircible diskette by ResQdisk and the F1-F2 keys sequence. The
  1286.  current boot areas can be restored later by ResQdisk.
  1287.  
  1288.  An alternative way to ResQdisk, for replacing the boot sector is by
  1289.  booting from a clean DOS diskette, necessarily of the same DOS version
  1290.  as installed on the hard disk and transferring a fresh sector by the
  1291.  command SYS C: The Rescue Diskette will normally contain the SYS.COM
  1292.  file and it may be used for the purpose. In case of a damaged or
  1293.  nullified boot sector, DOS will not let to renew the sector by the sys
  1294.  command (the message "invalid media type" is returned by DOS), and
  1295.  ResQdisk will become the only way to recover the drive.
  1296.  
  1297.  Recovery from Boot Stealth Viruses.
  1298.  
  1299.  The procedure that follows will probably never be necessary for the
  1300.  registered user, as boot spoofers are taken care of in IVINIT, right at
  1301.  boot time, as well as in IVSCAN. It is brought here mainly as a
  1302.  work-around for unregistered users and to explain the mechanics of boot
  1303.  spoofers.
  1304.  
  1305.  ResQdisk can be used for the recovery from boot stealth viruses.
  1306.  Inappropriate procedures with boot spoofers may cause the loss of
  1307.  access to the hard disk, as happens indeed with quite many scanner and
  1308.  TSR anti virus products. ResQdisk enables full recovery from viruses
  1309.  such as from Monkey, Newbug, Quox and many others.
  1310.  
  1311.  The presence of a boot stealth virus is announced by IVINIT or IVTEST,
  1312.  with the message "faked partition (or boot) sector". The virus is then
  1313.  sampled into a file labeled PARTVIR or BOOTVIR accordingly.
  1314.  
  1315.  Run ResQdisk and confirm the presence of the stealth virus by switching
  1316.  between SeeThru "ON" and "OFF" - with the F9 key, while watching the
  1317.  master partition sector, or the boot sector. Create a backup of the
  1318.  infected sector by pressing the "B" key, while SeeThru is OFF. The
  1319.  backup content is the true boot sector.
  1320.  
  1321.  Registered users may switch now the SeeThru to "ON" and restore the
  1322.  sector from the backup by pressing the "R" key. The original sector,
  1323.  rendered by the virus, will be written to the hard disk, in its right
  1324.  place. Unregistered users will have to run the above from a floppy,
  1325.  reboot the machine from clean DOS and then restore the original sector
  1326.  in place by running ResQdisk from the floppy.
  1327.  
  1328.  Exit ResQdisk and reboot the computer without running anything else!
  1329.  The computer will restart with a clean boot block. Note that the
  1330.  recovery from boot stealth viruses must run with the virus ACTIVE in
  1331.  memory!
  1332.  
  1333.  10.3 Fat Manipulators Removal
  1334.  
  1335.  The FAT manipulating viruses appeared at the end of 1991 and use a new
  1336.  method for propagation, based on the modification of the FAT pointers
  1337.  chain. There are now at least two widespread such viruses, DIR-2
  1338.  (Creeping Death) and 1963 (Niemela). These viruses are inherently
  1339.  stealthy and propagate extremely fast. Standard passive scanners are
  1340.  useless and harmful against these viruses. Countless hard disks were
  1341.  unnecessarily destroyed by the use of passive anti virus scanners
  1342.  against these two viruses. MSAV, the virus scanner distributed with
  1343.  Microsoft's MS-DOS 6, is an example of a passive scanner. Although it
  1344.  detects the 1963 (Niemela) virus and claims to clean it from infected
  1345.  files, in reality it ruins all the files it "cleans" from this virus.
  1346.  
  1347.  InVircible provides a totally safe and extremely efficient means for
  1348.  both the detection and the full recovery from these and other FAT
  1349.  manipulators. FAT manipulators are removed by an active Inverse
  1350.  Piggybacking process.
  1351.  
  1352.  The presence of DIR-2 or 1963 is detected by InVircible programs and
  1353.  is indicated by a warning message.
  1354.  
  1355.  In case a FAT manipulator virus activity is suspected, do not use the
  1356.  DOS CHKDSK/F switch, until the disk is completely disinfected! Using
  1357.  the /F switch while a FAT manipulating virus is active will cause
  1358.  massive and irreversible damage .
  1359.  
  1360.  10.4 Inverse Piggy-Backing (IP).
  1361.  
  1362.  The Inverse Piggy-Backing (also called cooperative virus removal) is a
  1363.  generic technique embedded in IVSCAN. It is based on forcing the
  1364.  infecting virus to disinfect its own doing. There are two available
  1365.  methods actually, labeled /M1 and /M2.
  1366.  
  1367.  Method 1 is effective against "light" stealthy infectors such as 4096
  1368.  (Frodo) and 1963 (Niemela).
  1369.  
  1370.  Method 2 is to be used to disinfect from the more "stubborn" ones such
  1371.  as DIR-2 and future FAT manipulators. Inverse Piggybacking is selected
  1372.  from IVMENU, from the Virus Scanner mode.
  1373.  
  1374.  The command line syntax for Inverse Piggybacking is:
  1375.  
  1376.                            IVSCAN drive: /Mn,
  1377.  
  1378.      /Mn being the method switch and "n" its number, for example, type
  1379.      IVSCAN C: /M1 to run method 1 on drive C.
  1380.  
  1381.  Inverse Piggy-Backing should start with the virus loaded in memory.
  1382.  Start by purposely running an infected file. In most case the operating
  1383.  system itself will be infected so that you may proceed directly to
  1384.  disinfection.
  1385.  
  1386.  The DIR-2 virus will lock up the computer if run under DOS-5 or
  1387.  DR-DOS-6. To disinfect from DIR-2 one should boot from DOS lower than 5.
  1388.  
  1389.  Method 1 is a single pass procedure. The processed drive will be
  1390.  operable after its completion.
  1391.  
  1392.  Method 2 requires two passes. On the first one COM/EXE files will be
  1393.  processed by the virus itself. A second pass with the IVSCAN /M3 switch
  1394.  restore the files to their original state. Disks processed with the /M2
  1395.  switch, except partition C,      will require processing with the /M3
  1396.  switch to have their executable files restored to original.
  1397.  
  1398.  Only partition C will be automatically cycled by M2/M3 processing. The
  1399.  IVSCAN.EXE program should reside on drive C for complete and automatic
  1400.  processing of this drive.
  1401.  
  1402.  Important! Turn off all disk caching before starting Inverse
  1403.  Piggybacking. Some disk caches oppose the IP technique. InVircible
  1404.  takes care of turning off the SMARTDRV.EXE cache. For other brands,
  1405.  consult the cache documentation on how to turn it off. Floppies and
  1406.  hard-disk partitions, other than C should be processed first. Partition
  1407.  C will be processed last. When finished with C, automatic rebooting
  1408.  will occur.
  1409.  
  1410.  Caution! Do not run any program, nor address the hard drive until
  1411.  rebooted, otherwise the drive will be immediately re infected.
  1412.  
  1413.  10.5 The Integrity Interrogation technique.
  1414.  
  1415.  This technique is a two step procedure. First, file database are
  1416.  established from an infected environment, then the files are restored
  1417.  by IVB , from a clean environment.
  1418.  
  1419.  The theoretical basis of this method lies in the fact that some viruses
  1420.  are so perfectly "stealthy", that they "show" the true uninfected file
  1421.  data to the operating system, when inquired about.
  1422.  
  1423.  Start by booting the computer from the infected drive itself. Make sure
  1424.  the virus is active by running a program known to be infected. IVB
  1425.  should be installed on the processed drive.
  1426.  
  1427.  Run IVB drive: /S (or the Secure option from IVMENU) on the entire
  1428.  directory or drive. Restart from the Rescue Diskette and run IVB in its
  1429.  Restore mode.
  1430.  
  1431.  10.6 Forced Self Restoration.
  1432.  
  1433.  The InVircible programs (except IVHELP, which is licensed from another
  1434.  vendor) will normally restore themselves in case they are attacked by a
  1435.  virus. In certain cases the program will get infected and stuck, thus
  1436.  inhibiting its self recovery. In such cases a little assistance from
  1437.  the user will be helpful: just type the infected program's name with
  1438.  the /FR (forced recovery) switch. For example, IVB/FR. Switch the
  1439.  computer off afterward since the virus may be now resident in memory.
  1440.  
  1441.  
  1442.  10.7 Screening New Software.
  1443.  
  1444.  InVircible is ideal for screening new software, to assure it is free of
  1445.  virus. Software screening is especially important in organizations,
  1446.  where viruses are usually introduced with new software, without having
  1447.  been screened first.
  1448.  
  1449.  The screening of software should be performed on an isolated computer
  1450.  (never when logged into a network). InVircible should be installed on
  1451.  the screening computer and a rescue diskette prepared for it.
  1452.  
  1453.  Install the new software on the hard disk according to its
  1454.  manufacturer's instructions, then "secure" it with IVB before actually
  1455.  running it. The new software should then be run and all its executable
  1456.  modules should be exercised. Reboot the computer from the rescue
  1457.  diskette and scan the hard disk with IVB for changes in files. Inspect
  1458.  the boot block for changes with ResQdisk. Compare the MBS and boot
  1459.  sector by individually "restoring" them from backup and watch for
  1460.  changes. Now reboot the computer from its own hard disk and watch for
  1461.  InVircible's warning messages. If all tests passed without findings
  1462.  then the software is most likely clean from known or unknown viruses.
  1463.  
  1464.  
  1465.  11. Importing InVircible into Windows
  1466.  
  1467.  InVircible is distributed with IV.PIF and IV.ICO files, to operate
  1468.  under Windows. Both files will be copied to the InVircible default
  1469.  directory by the Install utility.
  1470.  
  1471.  Start Windows normally and import InVircible into Windows by selecting
  1472.  New from the File menu and the Browse radio button. Use IV.PIF as the
  1473.  command line and IV.ICO as InVircible's icon.
  1474.  
  1475.  We also suggest to add Alt+Ctrl+V as the shortcut key, when in the
  1476.  properties change menu. Now InVircible can be activated from Windows by
  1477.  either double clicking on its icon, or by pressing Alt+Ctrl+V.
  1478.  
  1479.  As stated elsewhere in this guide, viruses operate only in the DOS
  1480.  environment. InVircible sometimes uses virus cooperative techniques.
  1481.  Viruses are not "well behaved" in an environment different from DOS.
  1482.  Therefore, it is recommended that only passive tasks such as integrity
  1483.  checking or virus scanning is done from Windows. Active disinfection,
  1484.  such as Inverse Piggybacking should not be attempted from Windows, but
  1485.  only from plain DOS.
  1486.  
  1487.  12. Virus Handling Under OS/2
  1488.  
  1489.  Computer viruses are often called DOS viruses, which implies that they
  1490.  are programmed to operate only under DOS. However, any operating system
  1491.  that is DOS compatible is susceptible to DOS viruses when in DOS
  1492.  compatibility mode.
  1493.  
  1494.  InVircible is compatible with the IBM OS/2+ operating system when in
  1495.  DOS mode. Because DOS internals are interpreted differently by OS/2,
  1496.  DOS viruses behave unexpectedly in an OS/2-DOS environment. Whenever
  1497.  InVircible detects viral activity in an OS/2 environment, proceed as
  1498.  follows:
  1499.  
  1500.  Simply COLD BOOT the computer from the Rescue Diskette and proceed
  1501.  normally with IVSCAN and IVB procedures. All virus disinfection should
  1502.  be undertaken only in a DOS environment. Do NOT attempt to boot DOS
  1503.  from the OS/2 dual booting system when viral activity is reported or
  1504.  suspected. When done, reboot the computer normally.
  1505.  
  1506.  
  1507.  13. Central Point Anti Virus Inoculation
  1508.  
  1509.  The CPAV Inoculation or self integrity check is the cause of many
  1510.  unexplained malfunctions. Many programs do not tolerate being
  1511.  inoculated, especially not DOS files, but not only them.
  1512.  
  1513.  The inoculation process consists of the encapsulation of executable
  1514.  files (COM and EXE) in a protective shell, like a cocoon. The
  1515.  inoculation adds about 700 or 900 bytes to COM and EXE files,
  1516.  respectively. The inoculation also modifies the programs in other ways.
  1517.  
  1518.  Inoculation has many drawbacks and practically no merits. First, the
  1519.  700 to 900 bytes added waste a lot of disk space. Second, inoculation
  1520.  causes programs to malfunction, especially under MS-DOS-6+. Third, the
  1521.  recovery of an immunized file will in most cases worsen the situation.
  1522.  In order to drop the virus the infected file must be run, at the risk
  1523.  of loading the virus into memory and infecting other files. And last,
  1524.  inoculation is useless against smart viruses and is not worth the
  1525.  trouble!
  1526.  
  1527.  Except for its malfunctions, there are good reasons why not to
  1528.  inoculate programs. The inoculation may hide a virus that infected the
  1529.  file prior to its inoculation. A dedicated virus may simply peel off
  1530.  the inoculation, infect the file and then re inoculate it as if nothing
  1531.  happened.
  1532.  
  1533.  InVircible will indicate files immunized by CPAV by either scanning
  1534.  with IVSCAN or IVB.
  1535.  
  1536.  Unfortunately there are differences between versions of CPAV, so it is
  1537.  safer to disimmunize files by the same product that inoculated them in
  1538.  the first place. Use the following procedure only if there is no other
  1539.  alternative, and with all precautions.
  1540.  
  1541.  Backup the files to be recovered. IVSCAN will remove the CPAV
  1542.  inoculation from files when in the virus "remove" mode.
  1543.  
  1544.  14. The Antivirus TSR (Terminate and Stay Resident).
  1545.  
  1546.  Memory resident programs (TSR) have been in use since computer viruses
  1547.  appeared in 1987. Their purpose is to prevent the penetration of a
  1548.  virus to the computer.
  1549.  
  1550.  Unfortunately, the TSR virus prevention is based on too many weak
  1551.  assumptions. Anti virus TSR look only for viruses included in their
  1552.  database. There are today as many as 5000 known viruses and their
  1553.  number increases at a constant rate of 50 to 100 per month. This number
  1554.  takes a heavy toll on the size of the database attached to the TSR and
  1555.  occupies precious memory space.
  1556.  
  1557.  Anti-virus TSR can be aggressive, affect the computer's performance,
  1558.  interfere with other applications, cause conflicts in memory and are
  1559.  potentially dangerous! For example, a typical and common AV TSR slows
  1560.  the computer by a factor of 3 to 5 and is notorious for having knocked
  1561.  out many hard disks that it was supposed to protect, without the
  1562.  slightest trace of any virus. The TSR simply defeated itself by
  1563.  derouting interrupt 13 (the one used for disk read and write) to
  1564.  deceive boot viruses, and fell in its own trap!
  1565.  
  1566.  TSRs need to be constantly updated. The assumption that the producer of
  1567.  the TSR will be the first to examine any new virus, proved to be false
  1568.  in most cases. The TSR is useless against new viruses, neither will it
  1569.  detect a known, but modified virus. Practically, a TSR older than six
  1570.  months is out-of-date, in most cases it is already obsolete at the date
  1571.  of its announcement. VSAFE, the anti-virus TSR distributed with MS-DOS
  1572.  6, is a grim reminder of this fact.
  1573.  
  1574.  Anti virus TSR suffer from false alarms and the higher the number of
  1575.  viruses a product detects, the higher is the rate of its false alarms.
  1576.  The common user has practically no means to distinguish between a false
  1577.  alarm and a real virus.
  1578.  
  1579.  Furthermore, TSR are incapable of distinguishing between a real virus
  1580.  and a faked signature, which explains their susceptibility to false
  1581.  alarms. For example, the following string of 10 bytes, when added to
  1582.  any program, will mislead McAfee's antivirus products to believe the
  1583.  program is infected with the Jerusalem virus. Consequently, VSHIELD
  1584.  (the TSR) will inhibit the execution of the program, SCAN will "detect"
  1585.  the Jeru-A virus and CLEAN will ravage the file containing the string
  1586.  as if it was really infected with "Jerusalem". The faked Jerusalem
  1587.  virus string, in hex notation:
  1588.  
  1589.                     03 F3 A5 26 C6 06 FE 03 CB 58
  1590.  
  1591.  AV TSR got bad reputation over the past years: the number of incidents
  1592.  in which anti-virus TSR were the direct cause of severe damage
  1593.  surpassed those caused by genuine viruses.
  1594.  
  1595.  Weighing the pros and cons for and against anti-virus TSR leads to the
  1596.  conclusion that TSR are a constant nuisance and threat to the health of
  1597.  your computer. The remote possibility that a TSR will really stop a
  1598.  banal virus attack, that could be removed anyway by less dangerous
  1599.  means, is not worth the trouble and the risks of the TSR!
  1600.  
  1601.  
  1602.  15. Procedures to Use if Virus Activity is Suspected.
  1603.  
  1604.  When dealing with computer viruses, awareness is the key to success. Do
  1605.  not improvise. Do not panic or act hastily. If there is no apparent
  1606.  damage, in most cases no further damage will occur until the computer
  1607.  is switched off and rebooted.
  1608.  
  1609.  Computer viruses are nothing else than programs themselves. A computer
  1610.  will not become infected unless an infected program is executed.
  1611.  Reading data cannot cause infection whatsoever!
  1612.  
  1613.  If you suspect the computer is infected with a virus, proceed as
  1614.  follows:
  1615.  
  1616.    a.  Do not switch the computer off immediately. If you have already
  1617.        turned off the computer, do not reboot the computer from its own
  1618.        hard-disk but rather from the Rescue-Diskette or from a clean and
  1619.        write-protected DOS floppy.
  1620.  
  1621.    b.  Save the data of the last job you were working on and exit
  1622.        normally from the application you were in. Do not start a new job
  1623.        as long as the computer wasn't verified and cleaned.
  1624.  
  1625.  The following steps will enable you to recover from a virus event with
  1626.  the minimum of disruption:
  1627.  
  1628.    a.  Have the Rescue Diskette always ready as well as a copy of your
  1629.        favorite backup program, both on write protected diskettes.
  1630.  
  1631.    b.  Boot from the Rescue Diskette and backup all important data.
  1632.        Programs can always be reloaded from original disks, data cannot.
  1633.        Copy several infected files to a diskette for later inspection.
  1634.        Do not start disinfecting the computer without completing the
  1635.        above steps. There is a possibility that irreversible things may
  1636.        happen in the course of virus removal. In fact, most of the
  1637.        damage caused by viral incidents is the result of inappropriate
  1638.        disinfection procedures.
  1639.  
  1640.    c.  After the system is cold rebooted from the Rescue Disk, first run
  1641.        IVSCAN to test for common viruses. Remove the viruses as
  1642.        described in section 10. Next run IVB.
  1643.  
  1644.    d.  After disinfection, do not hurry restoring files from backup,
  1645.        without verifying its contents first! The backups are likely to
  1646.        contain the same virus you just removed. Consider rebuilding your
  1647.        applications from the original software manufacturer's diskettes.
  1648.        Retain data only from the most recent backups, to minimize the
  1649.        possibility of repeated infections from your own backups.
  1650.  
  1651.  Viruses propagate in many ways. Smart viruses use stealth, self
  1652.  encryption or both. The more programs run, the higher the chances are
  1653.  of unintentionally activating a virus.
  1654.  
  1655.  Do not use shell programs or utilities while disinfecting a computer,
  1656.  certainly not from the infected disk itself. Do not run any program
  1657.  from the infected disk.
  1658.  
  1659.  Use plain and internal DOS commands such as DEL, REN, COPY etc. If you
  1660.  feel uncomfortable with these limitations, ask for assistance from a
  1661.  more knowledgeable user. All programs should be run from
  1662.  write-protected diskettes and reliable sources. The only exceptions are
  1663.  when explicitly instructed to work from an infected environment, such
  1664.  as for Inverse Piggybacking or Virus Interrogation, as explained
  1665.  elsewhere.
  1666.  
  1667.  Be consistent! Do not mix InVircible with other anti-virus software or
  1668.  hardware. Unraveling the results of mixing anti- virus methods is
  1669.  similar to attempting a medical diagnosis for an intoxicated patient
  1670.  that has swallowed multiple self- prescribed drugs.
  1671.  
  1672.  A virus in memory is a virus in control of the computer, while you may
  1673.  believe you are. Viruses are extremely deceitful programs, and will
  1674.  mislead even experienced users.
  1675.  
  1676.  Many viruses seek to infect the command interpreter. This is the file
  1677.  denominated by the environment string "COMSPEC" when typing the SET
  1678.  command. Therefore, it is good practice to replace the COMSPEC file
  1679.  from an original diskette. Also, rename the AUTOEXEC.BAT and the
  1680.  CONFIG.SYS to non-executable names until disinfection is completed.
  1681.  
  1682.  16. Practicing InVircible, the AV Practice Lab (AVPL).
  1683.  
  1684.  NetZ Computing provides a practicing environment named the Anti Virus
  1685.  Practice Lab (AVPL). AVPL is complementary to antivirus software and was
  1686.  developed for the purpose of practicing anti virus techniques in general
  1687.  and InVircible's in particular.
  1688.  
  1689.  It is best used in concert with InVircible. Yet it can be used with any
  1690.  AV product to learn about viruses and how to protect your PC and network
  1691.  against them.
  1692.  
  1693.  AVPL is a self contained tool that will let you practice several virus
  1694.  attack scenarios and how to recover from them. Although AVPL is designed
  1695.  to be used with the advanced generic anti-virus tools of InVircible, it
  1696.  can also be used to evaluate AV products in general.
  1697.  
  1698.  AVPL allows to "infect" selected computer programs in a virus like way,
  1699.  to install master boot sector (MBR) infectors to the hard disk, and to
  1700.  practice InVircible to identify the simulated viruses and recover from
  1701.  them. The "infections" produced by AVPL are ultimately harmless. The
  1702.  viruses created by AVPL will not replicate. They can not spread through a
  1703.  process of spontaneous replication to other programs or disks. They will
  1704.  only affect the program files in a target directory selected by the user
  1705.  and the hard drive of the system on which AVPL is installed. Therefore,
  1706.  the user can be assured that only those programs and the hard disk of
  1707.  their system can be affected by AVPL. AVPL will ONLY affect program files
  1708.  and the hard drive chosen by the user.
  1709.  
  1710.  Programs that are affected by AVPL can be "cleaned" either through the
  1711.  use of the Uninstall option of AVPL, through InVircible or through the
  1712.  DOS delete command.
  1713.  
  1714.  MBR infections that were installed by AVPL can be removed as well by
  1715.  AVPL's Uninstall option, or through the use of the ResQdiskette. It is
  1716.  important that you prepare a Rescue Diskette before you begin
  1717.  experimenting with AVPL.
  1718.  
  1719.  Prior to experimenting with AVPL please read its on-line hypertext guide.
  1720.  AVPL is available from all InVircible distributors as well as from
  1721.  anonymous ftp sites on Internet and BBS. AVPL is freeware, the file name
  1722.  of the package is AVPL101.ZIP.
  1723.  
  1724.  
  1725.  For Computer Security Experts and Advanced Users.
  1726.  
  1727.  Rehearse with real viruses on an isolated (not in a network) computer
  1728.  to get the feel of what a virus attack is like. Virus simulating
  1729.  programs are worthless in the forming of computer security experts. On
  1730.  the contrary, any anti-virus program that responds to a simulated virus
  1731.  is also susceptible to false alarms and will destroy programs in an
  1732.  attempt to remove an imaginary virus. Experiment only with
  1733.  "controllable" viruses such as Stoned, Jerusalem and Frodo (4096).
  1734.  
  1735.  And last, prepare a recovery plan and simulate it on a small scale,
  1736.  prior to being hit by a real computer virus. When the real thing
  1737.  happens, you will feel much more at ease if you have an idea of what a
  1738.  real virus attack is like and have practiced before.
  1739.  
  1740.  
  1741.  Appendix A. - LAN Protection
  1742.  
  1743.  The following describes how to implement InVircible for the protection
  1744.  of local area networks (LAN).
  1745.  
  1746.  At this date, there are no known viruses that affect the operation of
  1747.  Novell's Netware software. Yet, DOS viruses may affect executable and
  1748.  non executable DOS objects, stored on file servers. An infected object,
  1749.  such as a DOS shared application, when executed, can further spread the
  1750.  infection, from one workstation to another networked station.
  1751.  
  1752.  As a general rule, boot and MBR infectors, excluding multipartite ones,
  1753.  will not propagate through the network from one station to another. The
  1754.  effects of such viruses are retained locally and will not extend
  1755.  outside of the affected workstation. A file server can even be started
  1756.  with its MBR infected by Stoned or Michelangelo, and none of the other
  1757.  stations will suffer anything or even notice there is something wrong
  1758.  with the server hard disk!
  1759.  
  1760.  On the other hand, many file viruses can survive the Netware login
  1761.  process, or become active when already logged onto the network, and
  1762.  infect files on either the local disks, or on the file server.
  1763.  
  1764.  Virus Propagation in a Network.
  1765.  
  1766.  File viruses are usually categorized as direct action viruses and
  1767.  memory resident viruses. Some memory resident viruses are also known as
  1768.  "fast infectors" or piggybackers. All three terms refer to the
  1769.  propagation mechanism of file viruses. Direct action viruses infect
  1770.  additional file(s) every time an infected file is executed. Since the
  1771.  virus is not memory resident then the infection of more files will not
  1772.  occur on the execution of a program that is not actually infected. The
  1773.  criteria and pattern upon which additional files become infected can be
  1774.  anything: i.e. infecting files in the current directory, down the
  1775.  directories tree, along the DOS search path, at random etc.
  1776.  
  1777.  Memory resident viruses usually load into the workstation's memory,
  1778.  when the first infected file is executed. It doesnÆt matter where from
  1779.  it is executed, either from the local disk, or from the remote disk of
  1780.  the file server. From then on, any file that will be executed and fits
  1781.  the infection criteria of the particular virus (that is now
  1782.  memory-resident), will become infected itself. Many memory resident
  1783.  viruses have a direct action mode of infection too, in addition to the
  1784.  memory resident infection mode, as described above.
  1785.  
  1786.  Piggybackers are memory resident viruses that will infect any file that
  1787.  is "opened" or "closed" by the operating system. The programs that are
  1788.  the most likely to become carriers of fast infectors are virus scanners
  1789.  of all sort, as these programs are the only ones that ôopenö and
  1790.  ôcloseö every single program on a drive, while scanning them! It is
  1791.  thus essential that antivirus scanning programs, whether scanners or
  1792.  integrity checkers, be equipped with anti piggybacking features. For
  1793.  the moment, only InVircible has this ability.
  1794.  
  1795.  ItÆs reasonable to assume that all programs that were loaded to a file
  1796.  server were clean from viruses at the time they were loaded. Then how
  1797.  come that later on, some of these programs become infected? The answer
  1798.  is simple: An infection that originated from one of the workstations
  1799.  found its way to an application on the file server. If another
  1800.  workstation called and executed the infected program on the file
  1801.  server, then that stationÆs memory - and eventually its hard disk -
  1802.  will become an additional source for the spreading of the virus. Later
  1803.  on, the newly infected station will infect additional applications on
  1804.  the server.
  1805.  
  1806.  The most common pattern of how massive infections occur on file
  1807.  servers, and spread across the network to all workstations, is because
  1808.  of unaware network supervisors and the excessive use of virus scanners!
  1809.  the classical scenario is as follows: A new virus manages to infect a
  1810.  workstation. Most network managers unjustifiably rely on their
  1811.  scanner(s), anti virus TSR and on antivirus NLM. Being misled by a
  1812.  false sense of security, they overlook and reject the possibility that
  1813.  the scanner itself may be the source of an infection. Over
  1814.  self-confidence and ignorance are usually the excuse for not
  1815.  implementing better antivirus means than NLM scanners and TSR. Sooner
  1816.  or later, the supervisor will log-in with full read-write rights
  1817.  (supervisor or not ?!) and scan for viruses with a piggybacked scanner.
  1818.  The results are obvious.
  1819.  
  1820.  The lessons to be learned are:
  1821.  
  1822.  1. Since virus infections in network always start from a workstation,
  1823.     then workstations should be checked for virus presence prior to
  1824.     connecting to the network. Especially those PC that have local hard
  1825.     disk, as their chances to become infected are infinitely higher than
  1826.     those that boot from a network startup floppy, or from ROM-DOS.
  1827.     Antivirus that are initialized from the network, upon login, are
  1828.     stupid, insufficient, and worthless. The same applies to NLM too.
  1829.  
  1830.  2. Virus scanning of file servers should be run sparingly and with
  1831.     utmost precautions. Since piggybacking cannot be sensed on file
  1832.     servers, for technical reasons, then scanners should always be
  1833.     tested first on a local hard disk (never from a floppy) to give a
  1834.     piggybacker the opportunity to disclose its own presence. Only
  1835.     piggybacking resistant scanners should be used on file servers,
  1836.     unfortunately there is only a single such product on the market -
  1837.     IVSCAN from the InVircible package.
  1838.  
  1839.  Antivirus Protection in a Networked System.
  1840.  
  1841.  The strategy of how to protect a networked system from virus attacks
  1842.  consists of a few simple steps.
  1843.  
  1844.  First, have InVircible installed on all stations that have a hard disk.
  1845.  This way, every such station will be verified before the station has a
  1846.  chance to connect to the network and can contaminate the server. To
  1847.  facilitate the task, InVircible can be installed directly from the file
  1848.  server, to workstations having a hard disk. IV is provided with the
  1849.  IVLOGIN.EXE program. All that the supervisor need to do is to install
  1850.  IV into a dedicated directory on the server and invoke the IVLOGIN
  1851.  program from within the users login script. The following explains how
  1852.  to do it in a Novell network, every LAN manager knows how to adapt it
  1853.  to his own network brand. Suppose IV was installed to F:\PUBLIC\IV. Run
  1854.  SYSCON and select "Supervisor Options" from the menu, then select "User
  1855.  LOGIN Script". Add the following line into the script:
  1856.  
  1857.                        # F:\PUBLIC\IV\IVLOGIN.EXE
  1858.  
  1859.  Instead of virus scanning, better is to secure and verify the file
  1860.  server content with IVB, the integrity analyzer and generic restorer.
  1861.  This can be done through the following batch (CHECKSRV.BAT):
  1862.  
  1863.                      LOGIN SUPERVISOR
  1864.                      SET COMSPEC=C:\COMMAND.COM
  1865.                      C:\IV\IVB F: DAILY
  1866.  
  1867.  Line 1 provides full access rights, down to the root of drive F. Line 2
  1868.  returns the COMSPEC to drive C, since the file that contains the
  1869.  "daily" IVB verification data looks for to the root of where the
  1870.  COMSPEC is. Line 3 calls IVB to perform a daily check (once a day, on
  1871.  subsequent runs only the root directory will be verified) on all
  1872.  directories of drive F. If other than F volumes need to be verified,
  1873.  then line 3 can be duplicated, adding the other volumes, in an
  1874.  ascending order (from F to Z). If only a specific directory, and its
  1875.  sub-directories are to be verified, then add the directory after the
  1876.  volume name, e.g. F:\PUBLIC\APPL.
  1877.  
  1878.  It is recommended to run InVircible's Off-line Backup periodically,
  1879.  once a week, or twice a month. The Off- line Backup will produce a copy
  1880.  of the directories tree on floppy, with their respective signatures
  1881.  files, in case these were lost or tampered with. See elsewhere in this
  1882.  manual for how to run the off-line signature's tree backup.
  1883.  
  1884.  Cleaning a File Server from a Virus Attack.
  1885.  
  1886.  Whenever a virus is detected in a network, then act in an orderly way.
  1887.  
  1888.  While the virus is still active, try to obtain good virus samples on
  1889.  your local disk. Start by making sure that the COMSPEC points to the
  1890.  local disk (type SET to verify where to the COMSPEC variable points).
  1891.  Correct if necessary by typing SET COMSPEC=C:\COMMAND.COM. Run
  1892.  C:\IV\IVTEST, from the local disk. If lucky, IVTEST will generate two
  1893.  samples: Vir-Code and Virusam.ple. These will be valuable later,
  1894.  especially if the infection was caused by a variant or a new virus.
  1895.  
  1896.  Now proceed with the disinfection of the local disk. Use the rescue
  1897.  diskette if necessary. Try to locate the source of the infection on
  1898.  your own local disk by correlating with IVX. Consult the IV
  1899.  documentation if needed. During the disinfection of the local disk,
  1900.  learn the characteristics of the virus. If known by IVSCAN, then it's
  1901.  simple. If new or unknown to IVSCAN, then use IVB and note which type
  1902.  of files it infects (COM, EXE, SYS, OVL etc.), and what's the virus
  1903.  size. With IVX and the virus samples, find out what are the best
  1904.  correlation parameters to easily find all infected files, eliminating
  1905.  "noise" (detection threshold, correlation to Vir-Code and Virusam.ple,
  1906.  level of correlation, relative weight of statistical fitness, crypto
  1907.  model and string matching).
  1908.  
  1909.  When the local disk is totally clean, login to the network manually
  1910.  (execute the login batch line by line). Avoid the execution of any file
  1911.  from the server itself. Now assess the extent of the virus spread on
  1912.  the server by using IVSCAN (for viruses contained in its database), IVB
  1913.  and IVX. Before cleaning the server, shutdown all workstations in an
  1914.  orderly manner. All stations should be switched off, since the virus
  1915.  might still be memory resident. All the stations with hard disk should
  1916.  be disinfected individually before hooking them again to the network.
  1917.  
  1918.  The file server should be restored and cleaned in the following order.
  1919.  First use IVB/R for the fastest and best restoration of affected
  1920.  programs (provided they were secured beforehand). Next use IVSCAN /R,
  1921.  if the virus is known to IV, to restore those files missed by IVB (no
  1922.  signatures). If the virus is unknown to IVSCAN, then correlate with IVX
  1923.  to find out all files missed by IVB. Either rename the suspected files
  1924.  or delete them. Both options exist in IVX. Print the IVB/IVSCAN/IVX
  1925.  reports after each step. You may need to delete a few files that IVB
  1926.  could not restore, by using IVB/D.
  1927.  
  1928.  Replace the files that were renamed or deleted by IVB/IVSCAN/IVX (as in
  1929.  the reports' printout). Restart the network and resume operation.
  1930.  
  1931.  The methods described above should let you to resume network operation
  1932.  even after severe virus incidents, within half an hour to a couple of
  1933.  hours, while it could take a couple of days to a couple of weeks by
  1934.  other means.
  1935.